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The  value  of  timely  information  a3  an  aid  in  management  decision  making 
has  long  been  recognized.  For  veil  structured  and  predictable  problems, 
conventional  batch  processing  computer  techniques  and  Management  Information 
^Systems  technology  appear  to  be  capable  of  keeping  pace  with  the  rapidly 
increasing  information  needs.  However,  these  methods  are  inadequate  for  the 
type  of  unstructured  and  poorly  defined  problems  that  often  confront  high  level 
managers  —  whether- they  he  freer  the  military,  industry  or  government. 

It  appears  that  an  interactive  Management  Decision  System  (MDS) ,  operated 
and  directly  controlled  by  the  manager,  could  provide  significant  assistance 
in  making  the  required  decisions.  Biis  report  describes  a  prototype  system 
that  has  been  implemented  to  illustrate  and  evaluate  the  concept,  and  to  form 
a  basis  for  subsequent  research.^  Initial  experimentation  with  the  system  has 
been  very  encouraging,  and  some  preliminary  results  are  reported  here.  A 
more  useful  end  sophisticated  version  of  the  research  prototype  is  now  under 
development. 
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AB3TKACT 


The  value  of  timely  information  as  an  aid  in  management  decision 
making  has  long  been  recognised.  For  veil  structured  and  predictable 
problems,  conventional  natch  processing  computer  techniques  and  Manage¬ 
ment  Information  Systems  technology  appear  to  be  capable  of  keeping 
pace  with  the  rapidly  increasing  information  needs.  However,  these 
methods  are  inadequate  for  the  type  of  unstructureu  and  poorly  defined 
problems  that  often  confront  high  level  managers  -  whether  they  be  from 
the  military,  industry  or  government . 

It  appears  that  an  interactive  Management  Decision  System  (MDS) , 
operated  and  directly  controlled  by  the  manager,  could  provide  significant 
assistance  in  making  the  required  decisions.  This  report  describes  a 
prototype  system  that  has  been  implemented  to  Illustrate  and  evaluate 
the  concept,  and  to  form  a  basis  for  subsequent  research.  Initial  experi¬ 
mentation  with  the  system  has  been  very  encouraging,  and  some  preliminary 
results  are  reputed  here.  A  more  useful  and  sophisticated  version  of 
the  research  pr_„otype  is  now  under  development. 
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It  appears  that  an  interact :  vc  : [a :  agemen *  Dec :  u  .on  System  (M1)S), 
operated  and  directly  controlled  by  the  manager,  could  provide  signifi¬ 
cant.  assistance  in  making  the  require::  ueeictons.  A  previous  report  [l] 
summarized  preliminary  investigations  conducted  to  define  the  desirable 
characteristics  of  such  systems;  estimated  the  potential  need,  value 
and  applications;  and  evaluated  the  present  state  of  the  art  relative 
to  obtaining  the  desired  features. 


This  report  describes  a  prototype  system  that  lias  been  implemented 
in  order  to  illustrate  and  evaluate  the  above  findings,  and  to  form  a 
basis  for  subsequent  research.  A  number  of  lov  and  middle  level  managers 
have  experimented  with  the  system,  and  some  preliminary  results  are 
reported  here.  Based  on  the  promising  results  of  these  efforts,  a  system 
capable  of  performing  many  of  the  functions  specified  in  Ref.  1  is  being 
constructed.  The  design  specifications  for  this  system  will  be  described 
in  a  separate  report  [2]  to  be  issued  shortly. 


Section  II  discusses  the  role  and  value  of  prototype  (demonstration) 
models  in  the  design  of  interactive  software  systems,  and  thereby  provides 
the  motivation  and  justification  for  developing  this  particular  prototype 
system.  The  system  as  it  now  exists  is  described  in  Sec.  3.0,  and  a 
sample  scheduling  run  is  presented  in  Sec.  4.0.  The  results  and  conclusions 
of  the  effort  thus  far  sire  summarized  in  Sec.  5*0. 


2.0  USE  OF  DEMONSTRATION  MODELS  IN  THE  DESIGN  OF  INTERACTIVE  SYSTEMS 
2.1  Value  of  Prototype  Models 

The  value  of  working  prototypes  in  the  design  and  implementation  of 
on-line  interactive  systems  is  receiving  increasing  recognition  [3,4,5]. 
For  a  relatively  nominal  cost,  the  system  designer  can  build  a  working 
model  that  simulates  the  operation  of  the  conversational  portion  of  the 
contemplated  final  system.  (Note  that  such  models  are  not  required  for 
the  batch  portion  of; the  system  since  human  interaction  is  not  a  factor, 
and  sample  input  and' output  forms  can  be  manually  drawn  up  to  serve  the 
same  purpose.)  Usually  only  a  small  subset  of  the  system  capability  need 
be  modeled,,  and  the  data  base  organization  problems  are  greatly  simplified 
since  only  limited  artificial  data  is  required  for  this  purpose. 
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The  construction  of  demonstration  models  for  interactive  systems  is 
of  value  to  the  system  designer  in  Uiat  it  forces  a  formalization  of  his 
ideas,  and  gives  him  a  better  feel  for  cne  requirements  of  both  the  ultimate 
user  and  the  programmer  who  will  have  lo  implement  the  design.  The  pro¬ 
grammer  also  benefits,  since  he  gets  a  specific  am  concrete  example  of 
exactly  what  the  designer  expects  from  the  finished  product,  ierhape  the 
greatest  beneficiary  is  the  prospective  user  of  the  system.  It  is  a  form 
of  reference  with  which  he  can  readily  identify,  rather  than  a  somewhat 
abstract  description.  Experimentation  with  the  model  gives  him  a  better 
feel  for  the  eventual  end  product  ar.d  makes  it  easier  to  determine  and 
express  vhat  he  likes,  dislikes,  wants,  does  not  want,  etc.  Note  also 
that  changes  and  modifications  arc  almost  free  at  this  stage,  and  there 
is  a  great  deal  of  flexibility  to  make  modifications  and  to  experiment 
with  new  ideas.  Similar  experimentation  in  the  later  stages  of  develop¬ 
ment  comes  at  an  extremely  high  price. 

The  system  described  in  Secs.  3.0  and  4.0  can  be  placed  in  the 
same  category  as  these  demonstration  models.  It  was  constructed  in  a 
similar  manner  and  for  similar  experimental  purposes.  In  this  application 
emphasis  was  on  the  research  and  development  aspects  of  the  problem, 
rather  than  demonstrating  a  specific  system  or  capability.  However, 
because  of  the  close  parallels  with  demonstration  models  of  proposed 
operational  systems,  much  of  the  experience  is  directly  applicable  and 
analogous  benefits  were  derived. 

2.2  Determination  of  Information  Requirements 

One  of  the  most  difficult  and  critical  parts  of  any  interactive 
system  design  is  to  determine  the  actual  future  information  requirements 
of  the  organization  to  which  it  is  directed  -  i.e.,  to  find  out  what 
answers  (decision  help)  the  system  will  be  called  upon  to  provide.  It  is 
easy  to  state  that  one  should  study  existing  systems  and  methods,  and  then 
discuss  shortcomings  and  needs  with  the  appropriate  current  and  potential 
users.  However,  this  turns  out  to  be  easier  said  than  done.  Many  informa¬ 
tion  Bystem  design  groups  can  relate  their  experiences  of  circulating 
questionnaires  of  this  nature  ‘vnd  receiving  virtually  no  meaningful  response. 
Individual  managers,  when  approached  directly,  typically  will  have  little 
to  offer,  or  they  will  have  requests  that  are  incompatible  with  what  a 
reasonable  system  could  provide.  Constructive  answers  that  are  received 
are  often  based  on  the  capabilities  and  structure  of  the  system  they  are 
presently  uBing,  and  rarely  take  advantage  of  what  an  advanced  system  could 
provide.  One  is  tempted  to  conclude  that  the  people  to  whom  the  future 
interactive  system  will  be  directed  might  be  the  last  people  to  ask  for 
design  inputs.  However,  the  foolhardiness  of  proceeding  without  direct 
user .  involvement  has  often  been  demonstrated. 

The  construction  of  working  models  can  provide  a  solution  to  the 
above  dilemma.  Potential  system  users  can  be  placed  "on-line"  in  an 
environment  much  like  the  final  system  -  without  the  commitment  of  major 


.•ocourceij .  The  act  oi'  using  a  demonstration  model  can  then  provide  an 
excellent  vehicle  Tor  evaluating  the  requirements  of  the  future  system, 
since  it  permits  the  manager  to  think,  act,  and  function  in  a  manner 
that  closely  resembles  the  future  environment.  His  decisions  and 
requests  can  then  be  based  on  the  capabilities  of  the  future  system, 
instead  of  being  confined  by  familiarity  with  present  operations. 

2 . 1  Aid  to  System  Design 

Although  the  above  remarks  were  centered  around  the  determination 
of  future  information  requirements  of  the  system,  demonstration  models 
can  also  help  to  determine  such  factors  as  interface  language,  access 
devices,  response  time  requirements,  and  operating  environment.  This  is 
particularly  true  of  research  systems  like  the  one  developed  here.  Before 
attributing  these  benefits  to  demonstration  models,  however,  certain 
questions  must  first  be  answered.  For  example,  is  it  possible  to  construct 
such  models  quickly  and  cheaply  enough  to  justify  adding  their  cost  and 
time  to  that  of  the  overall  project?  Will  the  simplified  model  be  realis¬ 
tic  and  significant  enough  to  present  a  valid  representation  of  the  final 
system?  Will  proposed  users  take  the  time  and  effort  to  become  personally 
involved  during  this  early  stage  -  and  remain  involved  throughout  the 
entire  design  cycle?  The  results  of  this  effort  thus  far  appear  to 
reinforce  the  affirmative  answers  to  these  questions  given  in  Refs.  6,  7 
and  8. 

2 . 4  General  Ob  servat ions 


It  was  found  that  most  individuals  tested  thus  far  took  to  the  pro¬ 
totype  system  very  readily.  Ihey  learned  quickly,  and  generally  enjoyed 
the  experience.  More  important,  they  were  good  at  relating  the  particular 
model  used  to  the  types  of  problems  of  interest  to  them.  Useful  ideas 
were  often  received  and  new  applications  frequently  suggested. 

Based  on  these  experiences,  it  is  concluded  that  demonstration 
models  can  be  useful  tools  in  gaining  user  participation  and  support  during 
the  design  phases  of  interactive  systems.  In  this  study  users  often 
pointed  out  deficiencies  in  the  design  concept  and  in  the  implementation 
methods  and  provided  a  great  deal  of  useful  inputs  towards  correcting  them. 
In  general,  users  can  be  given  the  opportunity  to  become  educated  in  the 
use  of  interactive  tools  o^d  to  become  intimately  involved  in  the  early 
specification  and  design  of  the  eventual  system  -  without  expending  much 
time  or  resources.  Ihe  designer  also  benefits  by  obtaining  a  much  better 
feel  for  what  will  be  needed,  wanted  and  (more  important)  used  in  the 
future . 


3.0 


PROTOTYPE  SYSTEM  DESCRIPTION 


3.1  System  Description 

A  prototype  interactive  Management  Decision  System  for  planning 
has  been  implemented  using  the  General  Electric  Company's  commercial 
Mark  2  time-shared  system.  All  programming  is  in  standard  time  sharing 
Fortran  IV.  The  system  is  intended  to  provide  management  personnel  with 
the  capability  to  generate  limited  time-phased  scheduling  and  cost  data 
for  proposed  or  planned  products  and/or  projects.  Although  applicable  for 
control  over  the  total  life  cycle,  emphasis  is  oriented  towards  the  design 
and  planning  stages.  The  system  provides  a  convenient  technique  for  the 
exploration  and  evaluation  of  alternative  business  plans  and  schedules. 

By  also  entering  a  sales  forecast  or  description  of  expected  revenue, 
it  is  possible  to  estimate  such  financial  data  as  profit,  cash  flow, 
return  on  investment,  etc. 

A  sample  run  illustrating  the  entry  and  processing  of  planning 
data  (in  CPM  format)  is  given  in  Sec. 

The  overall  system  configuration  is  shown  in  Fig.  1.  Users  interface 
the  system  in  an  interactive  mode  via  on-line  teletypewriter  terminals. 

There  are  three  basic  system  modules  as  follows: 

1.  Planning  and  Control  Module  -  This  module  permits  the  examina¬ 
tion  of  proposed  projects  and  programs  and  the  costs  of  implementing  them. 

It  also  allows  for  the  input,  monitoring  and  updating  of  data  relative  to 
these  projects.  Provision  is  included  for  planning  and  schedule  analysis 
as  well  as  cost  summary  and  tabulation.  The  module  accepts  project  descrip¬ 
tions  in  any  of  three  basic  modes; 

a.  Critical  Path  Method  (CPM)  Network 

b.  Gantt  Chart  (Matrix  Format)  -  Cost  as  a  function  of  time 

for  each  activity 

c.  Cost  Profile  -  Cumulative  Cost  versus  Time 

The  Critical  Path  Method  (CPM)  network  module  permits  project  analysis 
by  activity  and  event.  For  each  activity,  the  user  must  specify  the  title, 
starting  and  ending  event  numbers,  cost  and  minimum  duration.  A  simple 
network  is  shown  in  Fig.  2.  The  standard  network  representation  is  given 
in  Fig.  2  and  the  equivalent  tabular  description  used  for  program  input 
and  output  is  shown  in  Table  I.  Since  the  starting  time  for  any  given 
activity  can  be  constrained  by  one  or  more  preceding  activities,  the  actual 
starting  times  for  many  activities  may  not  be  known  in  advance  and  a 
network  analysis  must  be  performed  to  determine  this  information. 

The  critical  CPM  notions  are  those  of  precedence  and  float.  For 
example,  the  engineering  and  marketing  functions  in  Fig.  2  cannot  start 
until  product  development  has  been  completed  (precedence) .  Also,  since 
the  six  months  required  for  marketing  is  three  months  less  than  the  sum 


Figure  1 

System  Configuration 
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INODE 


JNODE 


COST 


DURATION 


PROD.  BEVEL. 

1 

2 

j.6 

3 

ENGINEERING 

2 

1 6 

25 

3 

MANUFACTURING 

16 

5 

50 

6 

FIELD  SUPPORT 

5 

6 

10 

6 

MARKETING 

2 

5 

20 

6 

- 
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of  required  engineering  and  manufacturing  times,  there  is  a  slack  or 
"float"  associated  with  this  activity.  Therefore,  marketing  may  be 
spread  over  the  full  nine-month  period  without  delaying  project  comple¬ 
tion.  Analysis  routines  determine  such  parameters  as  the  permissible 
range  of  start  and  end  times  for  each  activity,  the  critical  path  and 
minimum  total  project  duration. 

The  Gantt  Chart  (matrix)  format  can  be  treated  as  a  special  case 
of  the  CPM  network  in  which  all  questions  of  precedence  and  float  have 
been  resolved.  Required  inputs  for  each  named  activity  are  reduced  to 
start  date,  duration,  cost  and  title.  The  user  can  input  in  this  form 
directly,  or  input  the  CPM  description  and  let  the  program  solve  for 
the  Gantt  chart .  Figure  3  Is  a  Gantt  chart  representation  of  the  CPM 
network  shown  in  Fig.  2.  The  same  datr  is  shown  in  matrix  form  as  Tfcble 
II.  In  this  example,  uhe  six  month  marketing  function  is  scheduled  to 
start  as  early  as  possible  (for  competitive  purposes)  and  to  end  as  early 
as  possible  (to  give  manufacturing  maximum  possible  lead  time) .  Note 
that  in  the  original  network  description  it  was  obvious  that  the  marketing 
time  span  could  have  been  expanded  by  up  to  three  months  (or  the  start 
date  relaxed  by  three  months)  without  affecting  the  total  project  life- 
cycle  schedule.  This  information  has  been  lost  in  the  simplified  descrip¬ 
tion  of  Fig.  3  and  Table  II. 
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Sable  II  -  Matrix  Fermat  (Cost  Distribution) 
Representation  of  Fig.  3 


ACTIVITY 

START 

DURATION 

(months) 

COST 

($K) 

PROD.  DEVEL. 

0 

3 

l6 

ENGINEERING 

3 

3 

25 

MARKETING 

3 

6 

20 

MANUFACTURING 

6 

6 

50 

FIELD  SUPPORT 

12 

6 

10 

Hie  Cost  Profile  (graphical)  format  is  used  in  those  situations 
when  only  total  project  cost  as  a  function  of  time  is  required.  These 
summary  costs  can  be  input  directly  or  computed  by  totaling  the  costs 
of  all  activities  described  in  the  matrix  format.  For  the  previous 
example,  the  cumulative  costs  are  plotted  in  Fig.  4a,  and  presented  in 
tabular  form  in  Fig.  4b. 
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18 
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Figure  4a  -  Graphical  Form  Figure  4b  -  Ttonlar  Fora 

Figu i*e  4  -  Graphical  Format 
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The  three  model  fonas  described  above  can  represent  successive 
simplifications  or  summaries  of  the  same  model.  The  CPM  network  model 
would  be  of  interest  to  a  program  or  manufacturing  manager,  for  example, 
whereas  the  tabular  summary  might  be  used  in  compiling  a  department  budget 
which  includes  many  such  programs.  Projects  may  be  described  in  any  of 
the  above  formats,  with  successive  simplifications  performvu  by  the  pro¬ 
gram  as  desired.  This  module  can  be  used  in  a  self-contained  manner  to 
help  derive  and/or  monitor  schedules  and  budgets,  or  its  r-vtputs  nay  be 
combined  with  those  of  the  sales  forecast  module  so  thac  profits  and  other 
data  can  be  estimated. 

2,  Forecasting  (Sales  Budget)  Module  -  At  present,  only  one  type 
of  Sales  Forecast  format  is  permitted.  This  is  the  "Revenue  Profile" 
which  is  identical  in  form  to  that  of  the  Graphical  Input,  or  Cost 
Profile,  described  for  the  Activity  Module.  Major  interest  in  this  module 
is  in  the  ability  to  input  a  Revenue  Estimate  that  can  later  be  compared 
with  the  scheduled  costs.  It  was  felt  that  there  was  little  to  be  gained 
in  understanding  by  providing  more  sophisticated  models  at  this  stage  of 
development,  provision  has  been  made  for  on-line  additions,'  deletions 
and  updates  to  all  revenue  files. 

3.  Analysis  and  Reporting  Module  -  Part  of  the  function  of  this 
module  is  to  provide  appropriate  eumma ry  end  reporting  (output)  capabilities 
for  models  built  In  any  of  the  above  formats.  In  addition,  If  compatible 
models  exist  for  both  the  scheduled  costs  and  the  salts  forecast;  the 
estimated  costs  of  operations  can  be  matched  against  projected  revenue  to 
determine  such  financial  data  as  profit  profile,  discounted  cash  flow, 
return  on  Investment,  break  even  point,  etc.  Seas  of  the  available  outputs 
ere  illustrated  in  Tables  III  and  IV,  and  in  the  plot  of  Fig.  5» 


Table  III  -  Profit  Analysis  Data 

— — . — .i  . . . — 

EXPECTED  LIFE  CYuJS  PROFIT  -  $11,805 
EXPECTED  LIES  CYCLE  $  PROFIT  - 

profit  ram  reflects  aw  annual 

COST  OP  MONEY  -  9*5$ 

RETURN  ON  INVESTMENT  »  1 3*1 


T -  ft  fi 

Net  return  on  investment  it  that  value  of  r  such  that  S  JY+rp- 


0. 


ti  ■  revenue  at  time  1  (can  be  +  or  -) 


Cteble  IV  -  Profit  lobulation 


Time 

Period 

(Quarter) 

Expected 

Profit 

($) 

Cumulative 

Profit 

(*) 

1 

-3000 

-3000 

2 

-2000 

-5000 

3 

-1500 

-6500 

4 

4000 

-2500 

5 

5000 

2500 

6 

4000 

6500 

7 

4400 

10900 

8 

905 

11805 
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3 • 2  System  Features 


1.  Fully  Interactive  -  The  system  is  fully  interactive  and 
designed  for  use  by  a  manager  with  little  or  no  prior  computer  experi¬ 
ence  or  preparation.  Input  requests  are  self-explanatory,  data  is 
entered  in  free  form,  and  instructions  are  provided  as  required. 

2.  Hierarchy  of  Model  lypes  -  The  planning  module  permits  a 
hierarchy  of  sophistication  of  model  description,  depending  on  the 
users'  needs  and  interests.  It  is  possible,  for  example,  to  use  the 
CPM  network  for  detailed  planning  and  control,  a  Gantt  chart  representa¬ 
tion  for  budgeting  purposes,  and  a  simple  cumulative  cost  compilation  for 
summary  comparisons. 

3.  Hierarchy  of  Organizational  Descriptions  -  In  addition  to  the 
hierarchy  of  model  types  described  above,  it  would  be  desirable  to  be  able 
to  represent  an  organizational  hierarchy  -  for  example,  to  permit  high 
level  control  over  total  costs,  and  detailed  project  level  control  over 
specific  activities-  This  capability  has  been  provided  for  illustrative 
purposes,  for  one  level  of  hierarchical  structure,  with  the  CFM  and  Gantt 
chart  formats  of  activity  models.  Listed  activities  may  be  grouped  into 
any  arbitrary  number  of  classifications.  Provision  has  been  made  to  name 
the  classifications,  to  assign  activities  to  classes  as  desired,  and  to 
compute  cost  subtotals  by  classification.  3he  classification  structure  can 
represent  activity  groupings,  organizational  level,  labor  category,  etc. 

If  no  classifications  are  assigned,  it  is  assumed  that  there  is  one  (unnamed) 
classification  to  which  all  activities  belong. 

4.  Hierarchy  of  Users  -  Each  user  can  select  a  model  type  that 
reflects  his  level  in  the  rrganisation  hierarchy.  Biis  level  will  also 
be  a  factor  in  the  use  and  selection  of  system  modules  and  options.  A 
production  manager,  for  suable,  might  build  a  detailed  CFM  production 
schedule  using  the  planning  module.  Cm  the  other  hand,  a  company  Vice- 
President  Interested  in  expected  profit  or  cash  flow  might  use  the  analysis 
module  to  combine  the  cumulative  costs  for  a  CPM  model  with  a  summary 

of  the  marketing  manager's  sales  forecast. 

5.  Modular  Construction  -  The  system  is  composed  of  self-contained 
program  modules  and  routines?”  This  permits  e  great  deal  of  flexibility 

in  system  use  and  operation.  In  addition,  the  modification  of  subroutines, 
the  substitution  of  different  computation  algorithms,  and  ths  addition  of 
new  program  modules  is  greatly  simplified. 

6.  Input-output  Formats  -  Input  is  entered  in  free  form,  usually 
by  responding  to  a  request  from  the  terminal.  For  simplicity,  output 
formats  are  fixed  and  predetermined,  although  there  is  flexibility  in 
selecting  the  desired  reports  and  report  forms.  At  the  user's  option, 
most  data  files  and  commutation  results  may  be  output  in  tabular  and/or 
graphical  (printer-plot)  fora. 
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3*3  Applications  and  'typical  Users 

Since  we  are  discussing  a  fairly  comprehensive  system,  useful  to 
many  people  for  many  diverse  purposes,  it  would  not  be  particularly 
enlightening  to  attempt  an  enumeration  of  possible  applications. 
Instead,  several  typical  uses  are  described  below  in  an  attempt  to 
indicate  the  diversity  of  applications  and  the  kind  of  decision  help 
that  could  be  rendered  from  an  operational  system  of  the  type  described 
here. 


1.  Production  Manager  (Program  Manager)  -  Hiis  user  would  be 
primarily  concerned  with  the  planning  and  control  module,  and  would  use 
that  module  in  great  depth.  He  may  use  the  output  of  other  modules  - 
for  example,  to  obtain  estimates  of  sales  (required  production  volume) 
from  the  forecasting  module  -  but  this  usage  would  be  secondary.  In  the 
proposal  or  planning  stages  of  projects  he  might  use  a  CPM  model  to 
establish  schedules,  estimate  costs,  prepare  budgets  and  resource  estimates, 
or  explore  alternative  implementation  procedures.  Later,  actual  expendi¬ 
tures  and  accomplishments  can  he  entered  and  the  system  used  to  generate 
status  reports,  predict  trends,  and  update  the  schedules  and  budgets.  Note 
that  at  any  point  in  time  the  process  of  changing  and  updating  can  be 
interpreted  as  either  future  planning  or  present  monitoring  and  control. 

2.  Contract  Monitor  and  Performance  Evaluation  -  A  government  or 
other  funding  organization  could  utilise  the  planning- and  control  module 
to  monitor  and  evaluate  the  performance  of  contractors.  The  initial 
schedule  could  be  supplied  by  the  vendor  or  entered  directly  from  the 
schedule  required  on  most  government  contracts.  In  addition  to  monitoring 
performar.ee,  the  model  could  be  used  to  examine  the  effects  of  potential 
problems  and  to  analyze  the  implications  of  contemplated  changes  in  contract 
scope  or  definition. 

3*  Mamgar  of  Marketing  -  Ibis  user  is  concerned  primarily  with 
the  forecasting  module,  although  he  may  use  cost  and  other  production  data 
from  the  operations  module.  He  is  interested  in  setting  sales  quotas, 
composing  budgets,  and  making  forecasts  for  various  possible  selling  prices, 
production  schedules  and  profit  profiles. 

4.  General  Manager  -  Assuming  that  the  above  production  and  mar¬ 
keting  managers  bad  bulls  model-  as  described,  a  higher-level  manager  might 
want  to  examine  summary  outputs  of  their  models  for  several  purposes* 

He  might,  for  example,  superimpose  the  cost  outputs  of  all  existing 
planning  models  to  estimate  the  total  costs  of  doing  business,  the  required 
cash  resources,  etc.  Alternatively,  he  might  want  to  superimpose  the 
sales  forecasts  to  get  estimates  of  total  expected  revenue,  or  he  might 
compare  expected  costs  with  the  sales  predictions  in  order  to  obtain  a 
pro-forma  profit  statement,  lhls  would  be  useful  in  making  decisions 
relative  to  product  selection  and  product  mix. 
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s .  proposal  Evaluation  -  A  military  or  other  government  agency 
might  use  such  a  system  to  model  and  compare  competitive  bids  as  a  tool 
in  contractor  selection.  The  capability  to  examine,  superimpose  and 
manipulate  various  proposed  schedules  (planning  and  scheduling  module) 
ana  funding  requests  (budgeting  module)  could  be  extremely  useful  in  com¬ 
paring  the  costs  and  potential  value  of  alternative  approaches  or  pro¬ 
posals. 
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Jt.O  SAMPLE  SCHEDULING  RUN  WIBi  PROTOTYPE  PLANNING  SYSTEM 
•t .  I  Sample  Problem 

Ac  an  example  oi‘  a  typical  scheduling  problem,  consider  the 
design  and  development  of  a  new  gas  storage  field  for  a  major  utility 
company.  This  project  could  represent  capital  expenditures  ranging  in 
the  millions  of  dollars.  The  activities  that  take  place  from  conception 
to  implementation  must  therefore  be  scheduled  for  optimum  utilization  of 
personnel  and  economy  of  resources. 

Before  the  actual  construction  work  is  started,  geological,  engineer¬ 
ing  and  cost  evaluations  must  be  made.  Next,  land  must  be  acquired  at 
the  field  location  and  at  all  necessary  right-of-way  and  pipeline  and 
compressor  station  areas.  Finally,  the  gathering  system  and  compressors 
must  be  constructed  and  the  wells  drilled. 

The  overall  flow  of  activities  for  such  a  hypothetical  project 
is  represented  by  the  Critical  Path  Method  (CPM)  diagram  of  Fig.  6.  The 
tasks  are  divided  into  three  categories  or  classifications:  evaluation, 
land  acquisition,  and  installation.  Since  there  is  a  separate  responsi¬ 
bility  for  each  of  these  areas,  the  activities  are  grouped  by  classifica¬ 
tion  as  shown  in  Table  V ,  and  separate  cost  subtotals  will  be  provided 
for  each  classification  category. 

Die  sample  run  to  be  described  represents  the  initial  step  in  the 
analysis  and  optimization  of  the  schedule  shown  in  Fig.  6.  Die  objective 
was  to  input  and  examine  the  Critical  Path  Method  description  of  the 
contemplated  project  schedule.  Diis  consisted  of  a  CPM  network  analysis 
and  solution,  and  the  derivation  of  various  summary  reports,  graphs  and 
charts  describing  the  solution  obtained. 

4.2  Sample  Run  Description 

One  way  to  organize  the  data  for  initial  program  input  is  to  draw 
a  diagram  like  that  of  Fig.  6.  Frequently,  this  initial  diagram  will  be 
a  simple  free-hand  sketch  with  the  complete  activity  descriptions  and 
classification  assignments  entered  directly  on  the  diagram.  Note  that 
neither  the  dates  (relative  to  time  zero)  for  performing  each  task  nor 
the  critical  path  is  obvious  at  this  stage  of  the  analysis. 

Die  sample  run  (Figs.  7a  to  7g)  should  be  relatively  self-explana¬ 
tory  and  will  not  be  discussed  in  detail.  It  is  of  interest,  however,  to 
summarize  the  overall  program  flow  with  reference  to  the  figures.  (Note 
that  underlined  items  represent  user  inputs  or  responses.)  After  the 
standard  system  sign-in  procedure,  the  executive  program  (LC1XEC)  is 
used  (Fig.  7a)  to  call  the  file  building  module  for  entering  a  new  CPM 
activity  file  in  the  file  previously  reserved  as  TESBL.  After  all  data 
has  been  entered,  control  is  switched  to  the  file  summary  and  modifica¬ 
tion  program  (Fig.  7b) .  This  program  is  used  to  display  the  stored  file 
data  and  to  correct  the  previous  input  errors  and  omissions. 
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Thble  V 


Classification  Groupings  for  Cample 


Problem 


Class  No.  Classification 

1  Evaluation  (EVA L) 

2  Acquisition  (AOQU) 


3 


Installation  (iNbi) 


lAsk  Id. 

GEVL 

EEVL 

crs. l 

GRPT 

ERPT 

CRPT 

cum 

LAOQ 

LEGL 

DUNE 

ISTK 

PEVL 

D&C 

cm 

CCON 

GSEV 

GSCT 

DUM3 


Class 

1 

1 

1 

1 

1 

1 

1 

2 

2 

2 

3 

3 

3 

3 

3 

3 

3 


Task 

•  ^logical  Evaluation 
Engineering  Evaluation 
Cost  Evaluation 
Geological  Report 
Engineering  Report 
Cop,:  Report 
Dumny  Task  No.  1 
Land  Acquisition 
Pinal  Legal  Work 
Dunsny  Desk  No.  2 
Integration  Study 
Field  EVaiuatio— 

Drilling  and  Completion,  of  Wells 
Compressor  Evaluation 
Compressor  Const  met  ion 
•lathering  System  Evaluation 
Gathering  System  Construction 
bmny  The k  No.  3 
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ir:ie  -  TM  analysis  modules  are  illustrated  in  Fig.  7c.  CFMONE 
■  •  j ■  * r. tiie  network  Tor  such  logical  inconsistencies  as  loops,  multiple 
.  tart.,  parallel  activities  and  multiple  end  events.  If  the  network  is 
io.-i'-ai  I y  .-orrect,  CPMTVO  then  carries  out  the  network  analysis.  In 
ad  ;it Lou  to  the  tabular  output  of  CPMTWO,  it  is  often  interesting  to  examine 
cbe  iata  in  bar  chart  form  as  shown  in  Fig*  7d.  If  all  aetivitiea  started 
as  curly  as  possible,  and  were  completed  as  early  as  possible,  the  project 
./ould  proceed  as  shown  by  the  *'s.  The  +'s  indicate  the  available  slack, 

;  i'  any,  for  each  activity.  Hence,  slippage  over  these  dates  will  not  affect 
the  critical  path.  The  solution  is  then  stored  in  Gantt  Chart  (standard) 
form  as  file  TLSTE . 

The  example  of  the  report  module  illustrated  in  Fig.  7e  shows  the 
output  of  the  standard  format  data  of  TEST2.  For  financial  purposes,  all 
cost  data  will  be  expressed  in  terms  of  the  present  value  (time  ■  0) 

of  mo-iey.  In  this  exanp.le,  a  12 $  annual  rate  is  assumed. 

......  :■<. 

Finally,  the  cumulative  costs  for  all  activities  are  confuted  as 
a  function  of  time  and  plotted  as  Fig.  These  results  are  shown  in 

tabular  form  in  Fig.  7g.  The  costs  are  also  saved  in  this  graphical  fom 
as  TEST3  in  case  the  need  to  access  or  manipulate  the  results  arises. 

The  emphasis  on  this  run  was  in  storing  and  analysing  ft  particular 
contemplated  CPK  schedule.  Future  runs  can  now  recall  any  of  the  stored 
descriptions  (CPM,  cost  distribution  chart,  or  graphical)  for  on-line 
modification,  update  and/or  report  generation. 
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MKII  011-017  09119  C 

USER  NO.-- 

PROJECT  ID--  _ 

SYSTEM- -FORTRAN 

NEW  OR  OLD- -OLD  LCEXEC 

READY 

RUN 


09*19  EOT  15  OCT  70 


SYSrg*  $***'-»*< 
tg*ee  P*o^ 


LCEXEC 


0920  EOT 


10/15/70 


L.  C.  EXECUTIVE  PROGRAM 

WORK  ON  A  PILE  (FILE)  OR  GENERATE  REPORTS< GEN)-- 7FILE 


CALL 

*9*>  QtAILOl*? 
piLtr 


ACTIVITY  (A)  OR  SAi.ES  FORECAST  (SF>  FILE— 7^. 

MULTIPLE  ACTIVITY  FILES— 7110. 

ACTIVITY  FILE  NAME  ■  TTESTl 

FILE  IS  CPM<C>*  STD(S>*  OR  QRAPH(0>— Tfi. 

OLD  OR  NEW  FILE- - 7NEW 
CHAINING  TO  FILE  BU1LDIN0  MODULE 

ENTER  NUMBER  OF  ACTIVITIES  IN  FlLEvMO*  OF  CLASSIFICATI0NST1 7*3 

INTER  CLASSIFICATION  NUMBERS  AND  CLASSIFICATION  NAMES 
»l  EVAL 

» OSS 

7  a  INST 

ENTER  ACTIVITY  RECORDS  WITH  FIELDS  IN  FOLLOWING  SEOUCNCEl 
INODE* JNODE*  DURATI ON*  COST*  CLASSIF* • TITLE* 


TS*  7*1*1  BOB*  **LACO 


Bnmtrm '»  *r*r  n»] 

WlM-VI'lQ 


T«»  B*  *»  II*  S*  DSCW 


0M -IL0 

CN* 

InimT 


nninoni.i.»M: 


LIFE-CYCLE  FILE -SUMMARY  AND  MODIFICATION  PROGRAM  DESIRED  7  (Y  ON  N) 

UL 

Fleur*  7* 

Build  Raw  CW  Flit 
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YOU  ARE  NOW  BEING  SWITCHED  TO  THE  LIFE-CYCLE  FILE 
-SUMMARY  AND  MODIFICATION  PROGRAM 

ACTIVITY  FILE  SUMMARY  REQUIRED?  -  fY  OR  N)?Y 


FILE  SUMMARY  -  TESTI  i‘TP***>  - . ,  * 

ACTIVITY  CLASSIFICATIONS 

RECORD  CLASSIFICATION  CLASSIFICATION 
NUMBER  NUMBER 


1  t  EVAL 

2  2  ACQU 

3  3  INST 


REC-NO* 

CLASS 

ACTIVITY 

I 

J 

DURATION 

COST 

4 

1 

GEVL 

1 

2 

3 

6 

S 

1 

EE  VL 

1 

3 

4 

12 

6 

1 

CEVL 

1 

4 

2 

1 

7 

1 

GRPT 

2 

s 

1 

2 

8 

1 

ERJ*T 

3 

s 

1 

2 

fmm  9 

1 

CRPT 

4 

s 

1 

1 

X->IO 

1 

OUNt 

4 

0 

• 

11 

2 

LACQ 

5 

7 

8 

1000 

12 

2 

LEGL 

7 

II 

3 

25 

13 

2 

0UN2 

6 

7 

e 

0 

14 

3 

3 

6 

8 

« 

2 

1 

as 

16 

3 

CEVL 

6 

t 

3 

as 

17 

3 

6SEV 

6 

18 

1 

s 

18 

3 

0«C 

8 

II 

12 

300 

It 

3 

CCON 

t 

II 

16 

2000 

28 

3 

OSC 

t« 

II 

8 

IMO 

FILE  TRUNCATION 

OR  SELECTIVE  DELETION 

REQUI RED?- <  Y 

OR  NlftL 

ACTIVITY  FILE  MODIFICATION  REQUIRED?  «<Y  ON  N>?]^ 
INTER  NO*  Or  MODIFICATIONS*  NO*  OF  ADDITIONS?  »*  I 


ENTER  MODIFICATION  RECORDS  IN  FOLLOVINO  FORMAT t 
REC-NO**  INODE*  JNODE.CLASSIF-NO**  DURATION*  COST*  TITLE 


1  38  25  FEVL 


It*** 

'0**»*s 


OUTER  ADDITIONAL  RECORDS  VI TH  FIELDS  IN  FOLLOVINO  SCO 
INODE*  JNODC*  DURATION*  COST*  CLAS5IF*N0**  TITLE 

>UULJ  »  ggj»,  a  or 

7  ACTIVITY  FILE  SUNMARY  REQUIRED?  -  (YFOR  N)  ?N^  ***** V 

FILE  TRUNCATION  OR  SELECTIVE  DELETION  RCQUlRCDf-tY  OR  NM*. 

ACTIVITY  FILE  NOOIFICATIQN  REQUIRED?  -<Y  OR  N) TflL- 


ACTIVITY  FILE  SUMMARY  REQUIRED?  -  (V  OR  H)  IJL. 

DO  YOU  VISH  TO  PROCESS  THIS  FILE  THROUGH  THE  CRM  MODEL?  -<Y  OR  N>?J^ 

Flfurt  To  -  .'usn&rlze  and  Modify  stortd  Pilt 
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YOU  ARE  BEING  SWITCHED  TO  THE.'CPM'  MODULE 
THIS  IS  CRM ONE  FOR  CHECKING  LOGIC  OF  CPM  NETWORK 


ACTIVITY  FILE  GENERICCG).  OR  UNIT  DATACU>??U 


TOTAL  PROJECT  CALCULATED  COST  =  S  4605 


DISTRIBUTION  OF  LIFE  CYCLE  COSTS  BY  CLASSI F 1  CAT I  ON  t 


CLASSIFICATION  I 
CLASSIFICATION  2 
CLASSIFICATION  3 


EVAL  -  S  24 
ACOU  >  S  1025 
INST  »  S  3556 


,li  oi*r 

e  CP”  _ 


START  EVENT  ■  II  ENO  EVENT  ■  II 

NO  LOGIC  OR  CONCEPT  ERRORS  IN  NETWORK  DESCRIPTION 
' 2PNTW0 *  IS  BEING  CALLED  TO  FIND  CRIT  PATH  AND  ANALYZE  THE  NETWORK 


CM  ANALYSIS  COMPLETE. 

CAN  SORT  OUTPUT  ON  ANY  OF  FOLLOWING  COLUMNS I 


I 

J 

OUR 

CAR  ST  CAR  FIN  LATE 

ST  L  FIN 

FLOAT 

LEV 

COST 

1 

8 

3 

4 

5  6 

7 

8 

9 

18 

what  column 

FOR 

SORT- -T  4^ 

> 

• 

c 

MNP 

MIN 

TOTAL  DURATION  *  861 

t 

© 

COST  -  4485 

CRIT 

I 

*1 

OUR  EAR  ST  EAR  FIN 

LATE  ST  L 

TIN  FLOAT 

LEV 

COST 

I 

8 

3  8 

3 

1 

4 

1 

1 

4 

• 

I 

3 

4  • 

4 

8 

4 

8 

1 

18 

1 

4 

8  • 

8 

8 

4 

8 

1 

I 

8 

s 

1  3 

4 

4 

5 

1 

8 

8 

8 

4 

•  3 

3 

4 

4 

1 

8 

8 

e 

3 

S 

1  4 

4 

9 

8 

t 

» 

4 

s 

1  4 

4 

5 

• 

3 

1 

• 

S 

4 

•  4 

4 

4 

4 

• 

8 

s 

Y 
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Figure  7f 
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.>.0  LUMMkHY  and  conclusions 

Hie  prototype  system  developed  permits  preliminary  project 
scheduling  and  costing  using  Critical  Path  Method  (CPM)  or  other 
planning  models;  the  entry  of  sales  forecast  or  expected  revenue  pro¬ 
files;  and  the  comparison  of  the  resultant  cost  and  revenue  estimates 
in  order  to  predict  profit  potential,  return  on  investment,  cash  flow, 
discounted  cash  flow  and  other  financial  data,  The  model  provides  a  help¬ 
ful  tool  for  the  planning  of  single  projects  or  programs.  It  is  also 
useful  in  demonstrating  the  operation  of  interactive  management  systems, 
particularly  to  those  without  previous  experience  with  interactive  computa¬ 
tion.  The  major  use  of  the  system  in  this  study,  however,  was  as  an 
experimental  vehicle  to  develop  techniques  and  evaluate  the  feasibility 
of  providing  managers  with  on-line  access  to  computer-based  planning, 
modeling  and  other  decision  making  tools. 

This  section  summarizes  the  more  general  preliminary  conclusions 
reached  after  limited  research  and  experimentation  with  the  prototype 
system  (re:  Secs.  3.0  and  4.0).  Detailed  results  relative  to  implementa¬ 
tion  such  as  user  language,  procedures,  system  content,  etc.  will  be 
incorporated  into  the  final  system  design  described  in  Ref.  2. 

In  general,  the  system  was  found  to  be  easy  to  learn  and  use,  and 
the  fast  response  and  absence  of  intermediaries  between  managers  and  the 
computer  is  felt  to  be  a  promising  combination.  One  problem  noted  was 
that  the  slow  output  speeds  of  the  teletypewriter  terminals  quickly  became 
tedious  as  user  efficiency  increased.  Hence,  although  it  is  desirable  to 
have  built-in  dictionaries,  tutorials,  and  other  user  guides  so  that  learn¬ 
ing  and  use  of  manuals  is  minimized,  users  should  not  be  forced  to  sit  at 
a  console  and  watch  while  unneeded  help  or  instructions  are  being  printed. 
The  moral  is:  provide  help  when,  and  only  when,  needed.  This  implies  that 
required  dialog  for  the  experienced  user  oust  be  minimised  and  high  speed 
output  devices  should  be  utilised  wherever  possible.  The  possible  sub¬ 
stitution  of  alphanumeric  cathode  ray  tube  (CRT)  display  consoles  for  the 
teletypewriter  is  being  given  strong  consideration. 

Based  on  the  above  experiences,  the  following  general  conclusions 
appear  valid: 

1.  The  Concept  of  interactive  Planning  Models  Appears  Promising  - 
The  study  results  are  veryenexjuraging  and  further  development  vorlc  is 
warranted.  Initial  Indications  from  the  prototype  system  are  that  managers 
find  it  easy  to  identify  with  and  use  this  type  of  program,  and  that  It 
can  be  useful  in  planning,  scheduling  and  other  decision  making.  The 
capability  for  large  scale  implementation  of  such  medals  is,  or  will 
shortly  be,  readily  available.  Required  application  programs  and  data 
files  are  already  being  developed  in  many  areas. 


2.  Ultimately,  Planning  Models  Should  Be  Operated  as  Integral 
Parts  of  Large  Management  Decision  Systems  -  The  real  potential  power 
of  such  tools  lies  in  their  ability  to  interact  with  and  complement 
other  parts  of  a  total  Management  Information  System.  This  can  provide  a 
substantial  increase  in  the  power  and  value  of  the  Information  System  at 
a  comparatively  nominal  incremental  cost.  Planning  models,  for  example, 
must  interact  with  sales  forecast  models,  financial  models,  business  Simu¬ 
lation  models,  and  large  banks  of  data. 

3>  State  of  the  Art  Shortcomings  are  Diminishing  -  There  are 
still  some  serious  shortcomings  in  available  hardware  and  software  that 
will  slow  the  development  of  the  desired  interactive  capability.  At 
ore sent ,  for  example,  available  input/output  terminals  suffer  from  such 
problems  as  being  too  slow,  too  expensive,  lacking  visual  (CRT)  and 
graphical  display  capability,  not  having  hard  copy  output,  etc.  In 
addition,  most  present  computer  systems  do  r.ot  yet  provide  adequate  time- 
shared  software.  There  are  no  (except  posBlbly  unpublished  proprietary) 
interactive  file  management  systems  of  adequate  capability  -  let  alone  inter¬ 
active  Management  Decision  Systems.  However,  all  of  these  areas  are 
receiving  much  attention  and  the  difficulties  are  diminishing  rapidly. 

Hence  it  is  not  expected  that  hardware  and  software  shortcomings  will 
present  major  barriers  to  the  successful  implementation  of  interactive 
systems. 


4.  Hierarchical  Models  and  Data  Bases  are  Required  -  The  programs 
and  data  bases  must  be  capable  of  functioning  with  e  hierarchy  of  levels  • 
each  representing  a  processed  subset  of  information  from  the  next  lover 
level.  Tb  some  extent  this  hierarchy  will  parallel  that  of  the  business 
organization.  A  project  manager,  for  example,  might  be  interested  in 
detailed  cost  and  schedule  data  relative  to  his  project,  while  his  super¬ 
visor  may  only  be  interested  in  comparing  and  combining  the  project  summary 
totals  with  those  of  several  other  projects.  The  levels  of  the  hierarchy 
are  closely  interrelated  and  one  of  the  key  system  requirements  is  the 
capability  to  move  freely  between  and  among  the  various  hierarchical  levels. 

5.  Information  Requirements  are  Difflctilt  to  Define  -  The  most 
difficult  part  of  ay stem  design  may  be" in  the  determination  of  the  future 
Information  and  decision  requirements  of  the  organization.  Few  methods 
exist  for  determining  the  information  requirements  in  specific  situations, 
or  for  identifying  the  general  requirements  of  a  wide  variety  of  managers. 
There  are  many  reasons  why  this  problem  exists.  Almost  by  definition, 
managers  have  learned  to  function  in  their  present  environment  and  with 
presently  available  information  sources.  Consequently,  they  are  often  not 
anxious  to  explore  ways  to  change  that  environment,  and  are  not  particularly 
aware  of  missing  information  or  the  value  of  new  or  more  responsive  sources 
or  forms  of  information. 

Frequently,  managers  are  not  as  enthusiastic  about  the  potential 
of  on-line  systems  as  one  would  anticipate.  Those  who  have  been  involved 
in  similar  problems  have  often  been  "burnt"  by  the  promises  of  computer 
hardware  and  (especially)  software  people  who  later  proved  to  be  unabl?  to 
meet  promised  costs,  schedules,  or  design  specifications.  Ac  a  result, 


manager:.;  are  bee  nnlng  increasingly  vary  when  the  subject  of  new 
computer-based  systems  is  brought  up.  This  problem  is  compounded  by 
the  unfamiliar ity  of  many  managers  with  the  potential  of  the  information 
field,  and  by  difficulty  of  putting  a  dollar  value  on  the  benefits  of 
obtaining  better  or  more  timely  results.  (Note  that  there  is  no  corres¬ 
ponding  difficulty  in  recognizing  the  large  capital  investment  needed  to 
build  and  operate  such  systems.) 

Sven  if  the  above  barriers  have  been  overcome,  the  problem  of 
determining  the  future  information  requirements  of  the  organization  is 
still  significant.  Knowledge  of  the  present  environment,  and  the  capa¬ 
bilities  and  shortcomings  of  the  present  system  and  procedures,  may  present 
a  very  narrow  and  limited  viewpoint  relative  to  the  potential  of  a  new 
system. 

6.  T*ny  Demonstration  Models  Can  Provide  Significant  Design  Help  - 
The  use  of  demonstration  models  as  was  done  here  could  alleviate  many 
early  design  and  communication  problems  by  giving  future  users  a  chance 
to  work  and  operate  in  an  environment  that  closely  resembles  the  proposed 
future  system.  This  could  be  done  before  any  significant  design  commit- 
u^-nts  are  made,  and  hence  permit  a  great  deal  of  experimentation  and  user 
involvement  during  the  early  phases  of  system  design. 
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